home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000294_news@newsmaster….columbia.edu _Tue Nov 18 10:32:09 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
115KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA29023
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 18 Nov 1997 10:32:09 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA26424
for kermit.misc@watsun; Tue, 18 Nov 1997 10:32:08 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Post FAQ?
Date: 18 Nov 1997 15:31:36 GMT
Organization: Columbia University
Lines: 2325
Message-ID: <64scco$h1q$1@apakabar.cc.columbia.edu>
References: <3470B666.11DC@supremecourt.gov>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8079
In article <3470B666.11DC@supremecourt.gov>,
Roy Buzdor <first.amendment@supremecourt.gov> wrote:
: Would it be possible to post the Kermit FAQ on a
: monthly, or quarterly basis for those of us who
: are fire-wall impaired?
:
It is rather long, but sure. Here it is:
KERMIT: FREQUENTLY ASKED QUESTIONS
>From the comp.protocols.kermit.misc newsgroup and elsewhere...
Most questions are already answered in the published documentation. Reading
the appropriate manuals (in conjunction with online release notes) will get you
started, answer most of your questions, and will let you get the most out of
your Kermit software: maximize the performance, write scripts to automate your
communications tasks, and so on. The Kermit effort is entirely
self-supporting, and proceeds from sales of these manuals is our primary source
of funding. So please do purchase the manuals.
Most recent update: 17 November 1997
Table of Contents
1 HOW TO FIND KERMIT SOFTWARE i
2 WHAT IS THE CURRENT VERSION OF KERMIT? i
3 WHERE TO GET KERMIT MANUALS i
4 WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? (IT ISN'T!) ii
5 MY BACKSPACE KEY DOESN'T WORK! ii
6 HOW DO I USE MS-DOS KERMIT OVER TRUMPET WINSOCK OR MS WfW TCP? iii
7 HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER? iv
8 WHERE IS THE KEY MAP FOR 3270 EMULATION? v
9 HOW CAN I MAKE MS-DOS KERMIT USE COM3, COM4? v
10 MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT. v
11 I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES v
12 BINARY FILES ARE CORRUPTED AFTER TRANSFER v
13 WHY DOESN'T THE HANGUP COMMAND WORK FOR ME? v
14 HOW CAN I MAKE THE DIAL/REDIAL COMMANDS KEEP TRYING? vi
15 I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED. vi
16 HOW DO I WRITE A SCRIPT TO DIAL A PAGER? vi
17 WHEN C-KERMIT DIALS MY V.32BIS (OR V.34) MODEM, I GET THE ERROR vi
'CAN'T CHANGE SPEED TO 14400 (OR 28800)'
18 HOW DO I USE KERMIT WITH PINE? vii
19 HOW DO I GET A SESSION LOG WITHOUT ALL THE EMBEDDED ESCAPE vii
SEQUENCES?
20 KERMIT DOESN'T WORK RIGHT WITH MY (RPI) ERROR-CORRECTING MODEM! vii
21 WHAT ABOUT WINMODEMS? viii
22 WHAT KIND OF MODEM SHOULD I BUY? viii
23 MY ARROW KEYS DON'T WORK viii
24 KERMIT UNDER WINDOWS CAN'T FIND MY PORT ix
25 IF I HAVE AN ERROR CORRECTING MODEM WHY DO I NEED KERMIT PROTOCOL? ix
26 HOW DO I USE 'SET KEY' WITH PC F-KEYS, ETC, IN UNIX OR VMS C-KERMIT? x
27 HOW CAN I EXIT FROM C-KERMIT WITHOUT HANGING UP? x
28 WHAT IS SUPERKERMIT? x
29 IS KERMIT SOFTWARE YEAR-2000 COMPLIANT? x
30 IS THERE A KERMIT LIBRARY? x
31 HOW DO I CALL UP A DIALBACK SERVICE? xi
32 HOW DOES THE NUMERIC KEYPAD WORK? xi
33 HOW TO GET RID OF THE "OK TO EXIT?" PROMPT? xi
34 HOW TO TELL KERMIT TO IGNORE DIALTONE? xi
35 WHERE IS THE DIALING SCRIPT FOR MY MODEM? xii
36 I'M HAVING TERMINAL EMULATION PROBLEMS WITH C-KERMIT xii
37 DIVIDE OVERFLOW IN MS-DOS KERMIT xii
-------------------------------------------------------------------------------
1 HOW TO FIND KERMIT SOFTWARE
World-Wide Web:
http://www.columbia.edu/kermit/
ftp: kermit.columbia.edu
This is the definitive source for Kermit software
on the Internet. Other Kermit archives or "mirror sites"
are not necessarily complete, accurate, or up to date.
Newsgroups:
comp.protocols.kermit.announce - Moderated
comp.protocols.kermit.misc - Unmoderated
E-mail:
kermit-orders@columbia.edu (Orders and order inquiries)
kermit-support@columbia.edu (Tech support)
kermit@columbia.edu (General -- not an FTP mail server!)
Post:
The Kermit Project
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Fax: +1 212 663-8202 or +1 212 662-6442
-------------------------------------------------------------------------------
2 WHAT IS THE CURRENT VERSION OF KERMIT?
Kermit 95 for Windows 95 and NT: 1.1.15 Sep 30 1997
Kermit 95 for OS/2: 1.1.15 Sep 30 1997
MS-DOS Kermit for DOS and Windows 3.x: 3.15 Sep 15 1997
C-Kermit for UNIX, VMS, AOS/VS, OS-9: 6.0.192 Sep 6 1996
C-Kermit for OS/2 1.x (16-bit: 5A(190) Oct 4 1994
C-Kermit for Stratus VOS: 6.0.192 Mar 7 1997
C-Kermit for Atari ST: 5A(189) Jun 30 1993
Mac Kermit (NOT A REAL RELEASE): 0.993(192) Jun 3 1996
IBM Mainframe Kermit: 4.3.1 Feb 10 1995
Kermit-11 for RT-11: 3.63 Sep 27 1997
Kermit-11 for RSX, RSTS, etc: 3.60 Jun 13 1989
Others (hundreds of them): See kermit/a/aavsys.hlp.
Also see the What's New section of our website.
-------------------------------------------------------------------------------
3 WHERE TO GET KERMIT MANUALS
MS-DOS Kermit, full-featured communications software for IBM and compatible PCs
with DOS or Windows 3.x, is documented in:
Christine M. Gianone, Using MS-DOS Kermit, Second Edition, Digital
Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN
1-55558-082-3. Packaged with the current version of MS-DOS Kermit for
the IBM PC, PS/2, and compatibles on a 3.5-inch diskette. In computer
and book stores, or order direct from Columbia University or from
Digital Press.
A German-language edition is also available:
Christine M. Gianone, MS-DOS Kermit, das universelle
Kommunikationsprogramm, Verlag Heinz Heise, Hannover, Germany (1991),
414 pages. Packaged with version 3.12 of MS-DOS Kermit for the IBM PC,
PS/2, and compatibles on a 5.25-inch diskette, including German-
language help files. Deutsch von Gisbert W. Selke. ISBN
3-88229-006-4.
And a French-language edition:
Christine M. Gianone, Kermit MS-DOS mode d'emploi, Deuxieme edition,
Heinz Schiefer & Cie., Versailles (1993), 406 pages. Packaged with
version 3.11 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on
a 5.25-inch diskette. Adaption francaise: Jean Dutertre. ISBN
2-901143-20-2.
There is also a Japanese book about MS-DOS Kermit, concentrating on the NEC
PC9801:
Hirofumi Fujii and Fukuko Yuasa, MS-Kermit Nyumon, Computer Today
Library 6, Saiensu-Sha Co., Ltd., publishers (1993), 160 pages. ISBN
4-7819-0669-9 C3355 P1854E.
C-Kermit 6.0, full-function communication software for UNIX, VMS, AOS/VS, VOS,
OS-9, QNX, the Commodore Amiga, and other platforms, is documented in:
Frank da Cruz and Christine M. Gianone, Using C-Kermit, Second Edition,
Digital Press / Butterworth-Heinemann, Woburn, MA, 1997, 622 pages,
ISBN 1-55558-164-1. In computer and book stores, or order direct from
Columbia University or from Digital Press.
A German-language edition is also available:
Frank da Cruz und Christine M. Gianone, C-Kermit--Einfuehrung und
Referenz, Verlag Heinz Heise, Hannover, Germany (1994). ISBN
3-88229-023-4. Deutsch von Gisbert W. Selke.
The Kermit File transfer protocol is specified in the following book, which
also includes tutorials on computers, file systems, data communications, and
using Kermit:
Frank da Cruz, Kermit, A File Transfer Protocol, Digital Press /
Butterworth-Heinemann, Worburn, MA, 1987, 379 pages, ISBN
0-932376-88-6. In computer and book stores, or order direct from
Columbia University or from Digital Press.
Kermit software for hundreds of different computers and operating systems is
available from Columbia University. Contact Columbia for a free Kermit
software catalog.
ENGLISH-LANGUAGE KERMIT BOOKS:
1. In computer and book stores, or order direct from the publisher,
Digital Press / Butterworth-Heinemann with MasterCard, Visa, or
American Express:
+1 800 366-2665 (Woburn, MA office for USA & Canada,
Toll-free M-F 8AM-6PM Eastern time)
+1 617 928 2613 (Newton, MA office for sales/marketing info)
+44 1865 314627 (Oxford, England distribution centre for
+61 03 9245 7111 (Melbourne, Vic, office for Australia & NZ)
+65 356-1968 (Singapore office for Malaysia, Singapore,
Indonesia, Philippines, Thailand)
+27 (31) 2683111 (Durban office for South Africa)
2. From Columbia University:
The Kermit Project
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Tel. +1 212 854-3703
Fax. +1 212 663-8202
E-Mail: kermit@columbia.edu
Domestic and overseas orders accepted. Add $10 US PER BOOK for
shipping outside of North America. Orders may be paid by MasterCard
or Visa, or prepaid by check in US dollars. Add $35 bank fee for
checks not drawn on a US bank. Price includes shipping. Do not
include sales tax. Quantity discounts are available. Single-copy
US prices (in US dollars):
Using MS-DOS Kermit . . . . . . . . . . . . . . . . .$ 39.95
Using C-Kermit . . . . . . . . . . . . . . . . . . . .$ 39.95
Kermit, A File Transfer Protocol . . . . . . . . . . .$ 34.95
All three . . . . . . . . . . . . . . . . . . . . . .$ 90.00
GERMAN-LANGUAGE KERMIT BOOKS:
MS-DOS Kermit, das universelle Kommunikationsprogramm: DM 79,00
C-Kermit--Einfuhrung und Referenz: . . . . . . . . . . DM 88,00
Verlag Heinz Heise GmbH & Co. KG
Helstorfer Strasse 7
D-30625 Hannover, GERMANY
Tel. +49 (05 11) 53 52-0
Fax. +49 (05 11) 53 52-1 29
FRENCH: Kermit MS-DOS Mode d'Emploi: . . . . . . . . . . . FF 495,00
Heinz Schiefer & Cie.
45 rue Henri de Regnier
F-78000 Versailles, FRANCE
Tel. +33 39 53 95 26
Fax. +33 39 02 39 71
JAPANESE: MS-Kermit Nyumon: . . . . . . . . . . . . . . . . . 1,800 Y
Saiensu-Sha Co., Ltd.
Abe-toku Building
2-4 Kanda-suda cho, Chiyoda-ku
Tokyo 101, JAPAN
Tel. +81-3-3256-1091
-------------------------------------------------------------------------------
4 WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? (IT ISN'T!)
Path: news.columbia.edu!usenet
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: [HELP] Slow Kermit Transfer ?!
Date: 19 Sep 1994 14:15:42 GMT
Organization: Columbia University
Lines: 153
In article <35jrgsINNdq2@newsman.csu.murdoch.edu.au>
anson@csuvax1.csu.murdoch.edu.au (Binh Anson) writes:
> I used Kermit 3.13 for my PC, my modem has a speed of 14.4 K, but I
> found that the downloading rate from the mainframe to my PC was
> still very slow! I tried Telix with SZ (Z-Modem Protocol), and it
> was very fast compared to Kermit. Is there a way to accelerate
> Kermit transfer ?
>
Yes.
But first, welcome to comp.protocols.kermit.misc. This is the first day of
operation of this unmoderated newsgroup. I hope it will prove beneficial to
all Kermit users.
To answer your question, somewhat longwindedly, since this Question is Asked so
Frequently :-) ...
Zmodem is optimized for speed on the assumption that it has a clear 8-bit
transparent channel with no blockages (small buffers, etc), and so, out of the
box, when it works it goes fast. The tradeoff is that it often does not work
at all, in which case you have to configure it in various ways -- escaping of
control characters, changing window size, etc. In some cases it can't be made
to work at all, either because of the nature of the connection, or because of
one or both of the computers on the two ends.
Kermit, on the other hand, is configured to work -- i.e. transfer files -- out
of the box, even under hostile conditions. By default, it does not assume that
control characters pass through transparently, nor that large buffers are
available. It does not even assume a full-duplex connection. The tradeoff is
speed.
In a perfect world, there would be no tradeoffs, but the world is far from
perfect. 7-bit transmission is still extremely common, small buffers are very
common, even in modern terminal servers and other communications processors,
flow control is rarely implemented correctly and effectively, telephone lines
are still noisy, and we still have a bewildering array of communication methods
needed for accessing different kinds of hosts and services. Most PCs are still
shipped with non-buffered UARTs; many PCs have interrupt conflicts, noisy
buses, etc; many modern modems are buggy. The list goes on. This is by way of
demonstrating that Kermit's default tuning is not crazy, and goes a long way
towards explaining its justified reputation for dependability.
Unfortunately, because of the tradeoffs necessary to achieve its reliability,
Kermit has a reputation for slowness:
Yes, Kermit transfers are slow if you use the default tuning.
However, you can make Kermit go as fast as the communication path will permit
by changing a few parameters. But first, here are some general principles that
apply to all communications software:
1. Ensure that you have an effective means of flow control enabled at
every juncture along the communication path (this applies to any
file transfer protocol). For example, when using high-speed,
error-correcting modems, you should use some form of hardware flow
control, most commonly RTS/CTS. You have to tell the software to
use it, AND you have to tell the modem to use it too -- if the flow
control methods of the PC and the modem do not agree, then data will
be lost. The same is true of the modem at the other end of the
connection, and the computer or device it is connected to.
2. If your modem is capable of data compression, use it. Fix the
interface speed of the software to four times the connection speed
if possible -- e.g. for a V.32bis 14400 bps connection, use an
interface speed of 57600, or else the modem's compression capacity
is likely to be wasted.
3. On network connections (e.g. TCP/IP), it is usually best to turn off
flow control entirely, because the underlying networking method
supplies fully effective flow control.
Now, to make Kermit go fast, follow these steps:
1. Use real Kermit software, not the many shareware and commercial
packages, most of whose Kermit protocol implementations lack the
performance features listed below and/or the means for the user to
control them.
2. Use long packets. Kermit's default packet length is 94. You can
increase it to a theoretical maximum of 9024. Give the following
command to the file receiver:
SET RECEIVE PACKET-LENGTH 2000 ; (or other length)
The longer you make the packets, the more efficient the file
transfer will be... IF IT WORKS. If you make packets longer than
some buffer somewhere along the line, and effective flow control is
lacking, the transfer might not work. Also, the longer the packet,
the greater the chance it will be hit by noise, and the longer it
takes to retransmit. A good starting value to try is 1000.
3. On full duplex connections, use sliding windows. Sliding windows
allow packets to be transmitted in a continuous stream, rather than
"stop and wait" style. The command is:
SET WINDOW 4 ; (or other number)
The maximum is 32 (or less, depending on the implementation). Give
this command to both Kermit programs.
For text files and uncompressed binary files, this should give you very good
performance -- efficiencies in the 85%-100% range.
For compressed files, and certain other types of binary files, you can squeeze
out another 20-25% efficiency by telling Kermit not to prefix a given list of
control characters. A typical sequence might be:
SET CONTROL UNPREFIX ALL ; Unprefix all control characters.
SET CONTROL PREFIX 0 1 13 129 141 ... ; Add back prefixes for these.
This might require some trial and error because there is no way that a
communication software program can know what characters are safe and which ones
are not on a particular connection. For example, you might be going through an
X.25 PAD where Ctrl-P will pop you back to the PAD prompt. Or you might be
going through a TELNET terminal server where Ctrl-] or Ctrl-^ will pop you back
to the terminal server prompt. Or the connection might be using Xon/Xoff flow
control, and sending Ctrl-S as a data character might freeze the connection.
If you take all of these steps, using optimal packet lengths, window sizes, and
unprefixing, you should achieve transfer rates comparable to, and often better
than, the Zmodem implementations that you find in Telix, Procomm, and similar
shareware and BBS packages; for example, on a V.32bis/V.42/V.42bis connection,
RTS/CTS flow control, no parity, 57600 bps interface speed:
Typical text files: 3500 cps (characters per second)
Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE)
Compressed files: 1600 cps (e.g. ZIP files)
These figures come from Kermit News #5, June 1993, which is available on the
Web and also via anonymous ftp from kermit.columbia.edu, directory kermit/e,
file newsn5.txt (ASCII) or newsn5.ps (PostScript). Also see Kermit News #4,
newsn4.txt (.ps), for a detailed discussion of long packets and sliding
windows. [As of late March 1995, there are also html versions of these files
suitable for Web access.] Kermit software is available via anonymous ftp to
kermit.columbia.edu [128.59.39.2], directory kermit and its subdirectories.
There are literally hundreds of different Kermit programs for *almost* every
machine and operating system imaginable. The most widely used Kermit programs
are:
- MS-DOS Kermit for DOS and Windows 3.x. No, this is not a native Windows
application, but yes, this is the Kermit software we recommend and support
for Windows 3.x. File: kermit/archives/msvibm.zip
- C-Kermit for UNIX, VMS, OS-9, AOS/VS, the Commodore Amiga, etc.
- IBM Mainframe Kermit-370 for VM/CMS, MVS/TSO, CICS, and MUSIC.
kermit/b/ik*.*.
- Frank
POSTSCRIPT: The Kermit software for Windows 95 and NT is Kermit 95. It was
first released in October 1995 (after this message was posted).
-------------------------------------------------------------------------------
5 MY BACKSPACE KEY DOESN'T WORK!
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: [?] Backspace key says, "^?"
Date: 7 Jan 1995 21:26:44 GMT
Organization: Columbia University
Lines: 122
In article <D201pG.DMB@indirect.com>,
Jim Monty <monty@indirect.com> wrote:
> DISCLAIMER: I've looked for the answer to the following question in
> _Using MS-DOS Kermit_ and in the documentation included with MS-DOS
> Kermit 3.13. I either couldn't find the answer or didn't understand
> it if I did.
>
Thank you for consulting the documentation.
> I'm using MS-DOS Kermit 3.13 on an i80386SX machine running MS-DOS
> 6.0, using a 14,400 bps Zoom VFP V.32bis modem. Kermit is set for
> VT220 terminal emulation and is using the Latin1 character set and
> code page CP437. I've not mucked with much in the initialization
> files, so you may assume that any other parameters are still set to
> the "factory" defaults.
>
> Alas, the question: In some online environments, my backspace key
> behaves as one would expect it to. In others, hitting the backspace
> key results in either (1) nothing happening, or (2) the characters
> "^?" appearing on the screen.
>
Or (3) the Backspace key acts like an Interrupt character on the host
(this usually happens with System V based UNIXes).
> I can, however, use Ctrl-H in these
> situations. In these exact same online environments (e.g., vi
> insert mode when connected to my dial-up UNIX shell account) under
> analagous circumstances, the other terminal emulator that I use,
> Telemate Version 3.12, does not behave this way. The backspace key
> functions as a destructive backspace.
>
> I presume that the change I need to make to my MS-DOS Kermit
> configuration is a simple one, but I can't figure it out. And I've
> never really wanted to bother to spend a lot of time trying to
> figure it out myself. (I want the magic straight from the wizards'
> minds.) Thanks, in advance, for taking the time to help me.
>
> Jim Monty, Kermit Cheerleader at Arthur Andersen LLP
>
Well, Jim, I think it's finally time to classify this as a Frequently Asked
Question and add it to the FAQ (kermit.columbia.edu:kermit/FAQ.TXT).
As you have discovered, different hosts and applications use different
characters (or sequences) for destructive backspace. The terminal emulator,
Kermit or otherwise (including Telemate -- if its backspace key works for you
in all circumstances, I think that's just a stroke of luck), has no way of
knowing what host or application you are using, and therefore no way of knowing
what to send when you press the Backspace key.
Of course, Kermit's Backspace key must send *something* "out of the box", so it
uses one of the several most likely destructive backspace values, and in fact
the one that is defined in ASCII to be destructive backspace, namely Rubout,
also known as Delete or DEL, character number 127, which sometimes is displayed
as "^?". Lest anyone believe this is a frivolous choice, I quote from American
National Standard X3.4-1977, Section 5.1, Control Characters:
0/8 BS (Backspace). A one-active-position format effector that moves
the position backward on the same line.
7/15 (DEL). A character used primarily to erase or obliterate an
erroneous or unwanted character...
In cases where the default does not work, Kermit lets you redefine the
Backspace key (or any other key) to send whatever you want it to send (or to
take any other actions) with the SET KEY command.
The SET KEY command has two operands: a unique identifier for a key or key
combination, called a scan code, and the value or action to be assigned to the
key. Scan codes are written with a preceding backslash (\). The scan code for
the Backspace key is \270. The default definition for this key is \127,
meaning the character whose numeric value is 127, i.e. DEL.
You can find out a key's scan code by consulting Table I-9 in the manual (pages
285-288), or by giving the SHOW KEY command to Kermit and then pressing the
desired key or key combination.
Now, as you have discovered, some applications use Ctrl-H -- ASCII BS
(Backspace) -- for destructive backspace. Consulting the ASCII table on page
275, you see that the ASCII code for BS is 8. So to make PC's Backspace key
send BS instead of DEL, give this command:
SET KEY \270 \8
If you use Kermit only to connect to hosts and services that use BS for
destructive backspace, then you can put this command in your MSCUSTOM.INI file,
and it will take effect automatically every time you start Kermit.
But some people (like yourself) switch between different hosts and/or services
that expect different characters or sequences for destructive backspace. You
can, of course, give Kermit the appropriate command every time you switch from
one to another:
SET KEY \270 \8 ; Backspace sends BS
or:
SET KEY \270 \127 ; Backspace sends DEL
or you can use the macros that are already defined in MSKERMIT.INI for this.
In version 3.14, for example, we have macros with names like VAX and IBM. The
VAX macro sets things up (including the Backspace key) for communicating with
VAXes and VAX-like systems, and that means, among other things, setting the
Backspace key to send DEL. The IBM macro, on the other hand, is used for
communicating with IBM mainframes in linemode, where BS is used.
You can use these macros as they are, or you can write your own macros based
upon them and add them to your MSCUSTOM.INI file. To use a macro, just type
its name at the MS-Kermit> prompt.
Suppose, for example, you normally access two different systems: a BBS (which
uses 8-bit characters, ANSI terminal emulation, and BS) and a UNIX system
(which uses 7-bit characters, VT220 emulation, and DEL), and these items need
to be changed when you switch between the two. You could write two macros such
as these:
define bbs set term byte 8, set term type ANSI, set key \270 \8
define unix set term byte 7, set term type vt220, set key \270 \127
And then each time you want to use the BBS, you just type "bbs" at the
MS-Kermit> prompt, and each time you want to access the UNIX system, you type
"unix".
Of course, you could take this process even further, and turn the BBS and UNIX
macros into complete connection-establishment and login scripts, following the
directions in Chapter 14 of the manual, on script programming.
- Frank
-------------------------------------------------------------------------------
6 HOW DO I USE MS-DOS KERMIT OVER TRUMPET WINSOCK OR MS WfW TCP?
Date: Sun, 8 Jan 95 13:27 EST
To: ....
From: kermit@columbia.edu
Subject: Re: Using Kermit with Trumpt Winsock
> I have an internet connection (SLIP) using Trumpet Winsock to
> establish the connection to the server under windows. I'd like to
> use kermit at that point to telnet to my company's computer. I've
> filled in the IP addresses in my custom file, but when I run kermit,
> and try to telnet, I get the message:
>
> Cannot attach to an Ethernet Packet Driver....
>
> Can you give me an idea of what I'm doing wrong?
>
The rule for DOS, Windows, and similar PC operating systems is:
ONE APPLICATION PER PROTOCOL PER NETWORK BOARD
This applies also to serial ports being used as if they were network boards,
e.g. via SLIP.
If you are talking about Windows 95 or Windows NT, you can use Kermit 95, which
does use Winsock -- any 32-bit Winsock stack (Microsoft, FTP Software, or
Trumpet).
If you are talking about Windows 3.x, read on.
Now, Trumpet Winsock is using (i.e. registered for) the TCP protocol on your
"network board". Thus, when you try to activate Kermit's own built-in TCP/IP
networking, it finds that it can't register TCP because TCP is already
registered. Thus it "Cannot attach to ... Packet Driver".
One might think it would be possible, then, to tell Kermit to "use" Winsock.
But Winsock TCP/IP stacks are strictly for pure Windows (and NT) programs, not
for DOS programs. MS-DOS Kermit is a "Windows-aware" DOS program, but a DOS
program nevertheless; it runs from the DOS prompt and within DOS emulator boxes
in various operating systems, and cannot access Winsock. If you want to make a
TCP/IP connection with MS-DOS Kermit when Winsock is running, you have to
unload Winsock and use Kermit's own built-in TCP/IP capability directly over an
Ethernet- or SLIP-class packet driver or an ODI driver. Or else install a
second network adapter. Or...
It is PERHAPS POSSIBLE, but not necessarily recommended, to run Kermit's TCP/IP
stack alongside of Winsock using Dan Lanciani's NDIS3PKT shim, or to use the
PKTMUX TCP/IP multiplexor. Use these methods at your own risk.
NDIS3PKT, in Dan's words:
"Ndis3pkt is a Windows virtual device (VxD) that provides multiple emulated
packet driver interfaces in Windows VMs and converts to NDIS3. It knows how to
route packets to the correct VM at upcall time (similar to the function of
WINPKT) and it includes an optional tcp multiplexor to allow multiple tcp/ip
stacks to coexist with the same IP address (similar to the function of PKTMUX).
It can also support multiple boards, but that isn't a much-used feature. It
can also emulate a class 1 (Ethernet) packet driver on top of Token Ring. In
other words, ndis3pkt is intended to be a one-stop solution to packet driver
applications over NDIS3.
"Now, when people talk about ``Winsock'' they often mean one of the Winsock
providing packages that runs in the Windows system VM, e.g., Trumpet. Because
Trumpet Winsock is really just another packet driver application, ndi3pkt is
perfectly happy to multiplex it along with any number of DOS applications.
Thus, from a high-level viewpoint, users see this as sharing DOS applications
with Winsock. In reality, ndis3pkt knows nothing about Winsock, but the net
effect is the same."
NDIS3PKT is in pub/ndis3pkt on newdev.harvard.edu, available by by anonymous
ftp. Be sure to read the license in the accompanying README file, and be sure
you have a version dated 17 Mar 95 or later.
NOTE: As of January 1997, this location has moved to:
ftp://hsdndev.harvard.edu/pub/ndis3pkt
http://ndtl.harvard.edu/ndis3pkt/
(Later, August 1995, more from Dan):
"Some people have been able to run kermit & MSTCP32 w/WfWG 3.11 together using
my ndis3pkt.386 driver. The trick is to use different IP addresses for MSTCP32
and kermit. More generally, you need one IP address for MSTCP32 and one IP
address for all your other packet-driver applications. This is because,
although ndis3pkt includes a tcp session multiplexor that allows multiple
packet-driver-based tcp/ip stacks to share the same IP address on one machine,
ndis3pkt has no control over the MSTCP32 stack. If you try to use the same
address for both, MSTCP32 will reset kermit's connections and such.
"Some people have been unable to get the MSTCP32+kermit+ndis3pkt combination to
work in configurations that appear superficially identical to those which work
elsewhere. I suspect there is some minor detail of interest to be found here,
but I don't know what it is. :)"
For additional details, see discussions in comp.protocols.tcp-ip.ibmpc and in
the ndis3pkt documentation.
PKTMUX, also a risky proposition, is nevertheless, reportedly used with success
at some sites. As one user reports, "I would not dismiss the use of a packet
driver, PKTMUX and as many PKTDRV stubs as you need. We use that setup with
TCP/IP Kermit, NCSA Telnet and winsock compliant apps. If you also use QEMM,
none of that takes ANY low memory and it is stable."
-------------------------------------------------------------------------------
7 HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER?
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit File Transfer and tn3270
Date: 16 Jan 1995 16:46:18 GMT
Organization: Columbia University
Lines: 169
In article <173276AEB.BDESIMON@uga.cc.uga.edu>,
Bert DeSimone <BDESIMON@UGA.CC.UGA.EDU> wrote:
> Gotta figure this has come up before. We are evaluating a terminal
> server that supports tn3270. No problem using MS-Kermit to connect
> to the terminal server and connect via tn3270 to an IBM mainframe.
> However, file transfers (either invoking server on the mainframe or
> not) always fail. Connecting through this same terminal server to
> the same mainframe through a 7171 presents *no* problem with file
> transfer. (BTW: I don't have to be using tn3270 on a terminal
> server; file transfers with Kermit using tn3270 on a Unix host fail
> the same way).
>
> I am speculating that the mainframe Kermit must send a transparent
> mode sequence, ordinarily processed by the protocol converter, that
> is causing the problem.
>
One of the major strengths of the Kermit protocol is its ability to transfer
files with IBM mainframes over a wide variety of connection types, and there is
an excellent Kermit software program for the IBM mainframe, which is available
for VM/CMS, MVS/TSO (and ROSCOE), CICS, and MUSIC. The current version is
4.3.1, with version 4.3.2 in beta test.
All of the Kermit books and manuals ("Kermit, A File Transfer Protocol", "Using
MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit online manuals)
describe the process(es) in some detail. Here is a brief summary.
Half-duplex (local-echo), line-at-a-time connections are generally handled by
the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which performs
the following protocol-related settings:
set local-echo on
set parity mark
set flow none
set handshake xon
Full-screen sessions go through a 3270 terminal emulator. This can reside
anywhere between the client software (such as MS-DOS Kermit) and the mainframe.
For the past 10 or 20 years, the most common place to find the 3270 emulator
was on a special purpose "protocol converter": a box that has serial lines on
one side and a connection to the mainframe on the other. This box generally
works by tricking the mainframe into thinking it is a "control unit" with
multiple 3270 terminals attached, and at the same time tricking the terminals
into thinking they are communicating with a "normal" ASCII character-at-a-time
host. The box converts between 3270 data streams and ASCII terminal (e.g.
VT100) conventions. This includes ASCII/EBCDIC character-set conversion,
cursor positioning and screen painting, and keystroke interpretation.
As you can imagine, all of these conversions would normally have a disastrous
effect on Kermit protocol packets, and also upon any other type of data that
has to be transmitted "as is", without conversion, such as graphics terminal
directives. Thus, many protocol converters support a "transparent mode", that
allows the mainframe host to command them to turn off their conversion
functions, and at a later time, turn them back on.
When everything works as planned, the only Kermit commands required for going
through the protocol converter are:
set flow xon/xoff ; (usually)
set parity even ; (or other)
Everything else corresponds to the normal Kermit defaults (remote echo, no
"handshake", etc).
Unfortunately, the method for entering and leaving transparent mode differs
from one 3270 emulation product to another. Ideally, there are two components:
(1) the identification phase, in which the mainframe software issues a special
instruction that causes the protcol converter to respond in a unique (but
harmless) way; and (2) the actual enter- and exit-transparent-mode directives.
IBM Mainframe Kermit needs to know which kind of transparency, if any, is used
by the protocol converter so it can be put into transparent mode at the
beginning of packet protocol and taken out of it upon return to interactive
command mode. There are several ways that mainframe Kermit can go about this.
First, you can use the SET CONTROLLER command to tell it which style of
transparency is used by the protocol converter. Second, mainframe Kermit can
be set up by the system administrator to always use a particular style. Third,
it can attempt to "autodiscover" the controller type by issuing various types
of identification queries and checking the results. The third method is not
very reliable, however, since many types of protocol converters fail to respond
to these queries even when they do implement a particular style of
transparency.
Nowadays, special-purpose protocol converters are giving way to general purpose
terminal and compute servers that include a "tn3270" function. tn3270 is a
special kind of TELNET program that also performs 3270 emulation, and requires
that the mainframe be on a TCP/IP network and have a TN3270 server. Here are
some examples:
1. UNIX tn3270. Most UNIX systems come with a tn3270 program that lets
you make a full-screen connection to an IBM mainframe. Once you
have made the connection, you should be able to start Kermit on the
mainframe, give it a SEND, RECEIVE, or SERVER command, escape back
to your terminal emulator (e.g. MS-DOS Kermit), and transfer files
without any special settings. If you have trouble with this, then:
- Ask mainframe Kermit to "show controller". If it doesn't say
Series/1, then tell it to "set controller series1".
- Try using shorter packets. The maximum length that can pass
through the protocol converter might be less than what you are
trying to use. A typical maximum value might be 1700.
- Tell one or both Kermit programs to "set parity space".
2. VMS tn3270. Depends on the TCP/IP version. TGV Multinet, for
example, does not claim to support transparent mode.
3. Cisco terminal server tn3270. Current releases of Cisco terminal
server software include a tn3270 feature that is supposed to permit
Kermit transfers, but it has bugs. Sometimes these bugs can be
worked around by using the methods listed in (1) above and
specifying VERY short packets, like 30 or 40 bytes. Sometimes they
can't be worked around at all. A future release of Cisco software
(probably 10.3) will include new tn3270 software that implements
Series/1-style transparency correctly, and allows Kermit transfers
of both text and binary files in both directions using packet
lengths up to about 1900 (or whatever the total screen size is).
If you try all of these workarounds with your terminal server and still get
failed transfers, make packet logs and/or debug logs in both Kermit programs to
find out what the terminal server is delivering to each Kermit program, and
report the misbehavior to your terminal server vendor.
For further information about specific protocol converters and how to configure
IBM Mainframe Kermit for them, please read the ik0aaa.hlp file that comes with
IBM Mainframe Kermit.
Finally, it is possible to transfer files through a 3270 fullscreen connection
even when 3270 emulator can't be put into transparent mode at all. You can
read about this in the second edition of Using C-Kermit and the MS-DOS Kermit
update notes file (KERMIT.UPD). Quoting from the latter:
"Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes
through 3270 protocol converters that do NOT support transparent mode, to be
used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN
command on VM/CMS, MVS/TSO, or CICS. MS-DOS Kermit 3.13 or later and IBM
Mainframe Kermit 4.2.3 or later required. Commands:
SET PARITY EVEN ; Or whatever
SET FLOW XON/XOFF ; Or whatever
SET SEND START 62 ; Greater-than sign
SET RECEIVE START 62 ; Ditto
SET BLOCK BLANK-FREE-2 ; New block-check type
SET HANDSHAKE NONE
BLANK-FREE-2 is a new block-check type, exactly like type 2, except encoded to
never contains blanks. Give IBM Mainframe Kermit the following commands:
SET CONTROLLER FULL
SET SEND START 62
SET RECEIVE START 62
SET BLOCK BLANK-FREE-2
SET HANDSHAKE 0
Doomsday Kermit file transfers are not as reliable as regular Kermit protocol
transfers, and they are much slower. Use this method only as a last resort;
that is, only when you can't get a transparent-mode fullscreen connection or a
linemode connection to the mainframe.
(end quote)
And beyond finally: in the future, we expect to add 3270 emulation to the
Kermit software itself, so you will be able to make tn3270 connections directly
from Kermit to the mainframe without having to go through a "black box" for the
conversion. Of course, Kermit software will handle transparency correctly (and
automatically). (And no, I can't estimate when built-in 3270 emulation will be
available.)
- Frank
-------------------------------------------------------------------------------
8 WHERE IS THE KEY MAP FOR 3270 EMULATION?
Real 3270 terminals have all sorts of keys that regular ASCII terminals (and
PCs and Macintoshes and UNIX workstations, etc) do not have.
A big part of the job of a 3270 protocol converter is to convert between ASCII
keystrokes (including escape sequences) and 3270 keys such as PA1 through PA3
and PF1 through PF24.
The administrator of the 3270 protocol converter creates the mapping. So in
order to make a 3270 key map for Kermit, you first have to find out what the
mapping in the protocol converter is, and then assign the ASCII values
(characters or sequences) that correspond to each 3270 key to the desired PC
(or Mac, etc) key.
It is the responsibility of each site administrator to document the key
mappings used by its protocol converters. Once you know the ASCII values that
correspond to each 3270 key, then it's easy to create Kermit key bindings.
For example, suppose the 3270 "cursor left" function (left arrow) is mapped to
ASCII Ctrl-B (ASCII character 2). Then in MS-DOS Kermit you would:
SET KEY \4427 \2
where \4427 is the scan code of the PC's (gray) left arrow key, and \2 is the
code for the ASCII value of the Ctrl-B character.
-------------------------------------------------------------------------------
9 HOW CAN I MAKE MS-DOS KERMIT USE COM3, COM4?
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: COM3 available in 3.14?
Date: 20 Jan 1995 15:48:20 GMT
Organization: Columbia University
In article <1995Jan19.232004.8689@midway.uchicago.edu>,
Cal Lott <cal@gsbux1.uchicago.edu> wrote:
> I was simply wondering if version 3.14 (or any earlier) could
> address COM3 and above.
>
A frequently asked question. The short answer: Yes.
The medium answer: COM3 and above have no standard address or IRQ, hence
communications software (Kermit or anything else) can't always find them, in
which case you have to specify the address and IRQ, using a sequence like:
SET COM3 \x3e8 5
SET PORT COM3
(You need both commands, in the order shown.) You must also beware of
"missing" COM ports. To use (say) an internal modem as COM4 when there is no
COM3 is not straightforward.
The long answer: Read section 6 of the KERMIT.BWR file on your MS-DOS Kermit
3.14 diskette (the version at kermit.columbia.edu in kermit/a, file mskerm.bwr,
might be newer).
- Frank
-------------------------------------------------------------------------------
10 MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT.
Since the release of MS-DOS Kermit 3.14, there have been persistent reports
that patches don't seem to "stick". That is, after giving a PATCH command, the
patch level is still reported as 0. This can happen if the patch file is
transferred to the PC from a UNIX system in binary mode, so the lines end with
LF rather than CRLF -- DOS does not recognize the line boundaries and therefore
Kermit does not see valid patches. Cure: make sure each line ends with CRLF.
Fix it in an editor, or re-transfer the file in text mode.
Also, remember there is no longer a need to rename the patch file to
MSKERMIT.PCH. Since there are now three different Kermit executables, there
must be three corresponding patch files. For version 3.14, these are:
MSR314.PCH -- For full-featured KERMIT.EXE
MSRM314.PCH -- For "medium-size" KERMITE.EXE
MSRL314.PCH -- For "Kermit Lite" KERLITE.EXE
Notice that each patch file includes the version number as part of its name.
This allows you to run different versions of Kermit without confusion about
patching.
-------------------------------------------------------------------------------
11 I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES
Here are the causes (and cures) listed in decreasing order of likelihood:
1. You are going through a terminal server or other type of connection
(telnet, rlogin, etc) that chops off the 8th bit. Kermit can't tell
that this is happening (as it can with devices that add even, odd,
or mark parity), so you have to tell it. The command is:
SET PARITY SPACE
2. You have used the SET CONTROL CONTROL UNPREFIX command to unprefix
one or more control characters that are not safe. Tell Kermit to:
SET CONTROL PREFIX ALL
and see if it works. If so, you'll have to home in on the
offender(s).
-------------------------------------------------------------------------------
12 BINARY FILES ARE CORRUPTED AFTER TRANSFER
Some non-Columbia Kermit implementations simply do not work, including some
found in BBS software. For example, if you download a file from a BBS using
their Kermit protocol option and find a lot of Ctrl-Ys in your file where only
actual letter Y's should be, then the BBS has a broken Kermit implementation.
The same is also true if a file downloaded from a BBS in binary mode is bigger
than the original. Ask your BBS sysop to install MS-DOS Kermit ("Kermit Lite")
as an external protocol. See the KERMIT.UPD file in the MS-DOS Kermit 3.14
distribution for additional information.
The more common cause, however, for "corrupted" binary files is that they were
transfered in text mode.
Both Kermit and ftp transfer files in text mode by default. This means that
record formats and character sets are likely to be converted. You can tell
Kermit to skip all conversions and transfer the file literally, as-is, with the
command:
SET FILE TYPE BINARY
Normally, it is sufficient to give this command to the FILE SENDER before
giving it the SEND command. But there are some exceptions to this rule:
1. One or both Kermits do not support "Attribute packets" (or they are
disabled). This is true of many of the commercial and shareware
Kermit implementations. Cure: tell BOTH Kermits to use binary mode.
2. You are using some combination of C-Kermit 5A(190) or later, MS-DOS
Kermit 3.14 or later, or IBM Mainframe Kermit 4.3.1 or later in
client server mode. In this case, it is the CLIENT's file type
setting, rather than the file sender's, that prevails. Cure: tell
the CLIENT to SET FILE TYPE BINARY, or to be extra sure, tell them
both.
3. You are sending the file from VMS C-Kermit, which is unique among
Kermit programs in its ability to automatically switch between text
and binary mode based on the file's characteristics. VMS C-Kermit
ignores SET FILE TYPE BINARY and SET FILE TYPE TEXT when sending
files, and instead uses binary mode if the file's record format is
Fixed, and text mode otherwise. However, some binary files, notably
VMS ZIP files, are stored using a "text-style" record format
(Stream_LF), so Kermit sends them in text mode. You can override
this by telling it to SET FILE TYPE IMAGE.
If you follow all these directions and binary transfers still come out wrong,
then perhaps the file you were downloading was corrupt to begin with -- e.g.
it was ftp'd in text mode instead of binary mode.
-------------------------------------------------------------------------------
13 WHY DOESN'T THE HANGUP COMMAND WORK FOR ME?
On network connections, Kermit's HANGUP command executes the appropriate
network protocol for closing the connection, and this should always work.
On serial connections, the HANGUP commands turns off the computer's DTR (Data
Terminal Ready) signal for a period of time. According to the standard that
governs modem signals, this action is supposed to make a modem hang up the
phone call. If it doesn't:
1. Your modem has been configured to "Ignore DTR". This setting is
available on most Hayes-compatible modems, either on a physical
switch (such as Configuration Switch 1 on the Hayes 1200) or as a
command (&Dx on Hayes 2400 and later, and compatibles). In many
cases, "Ignore DTR" is the factory setting. If you want your modem
to obey the DTR signal, then you should set the switch
appropriately, or give the command AT&D2. The actual syntax of the
command might vary among different brands and models of modems, so
consult your modem manual for details.
2. Your cable or connector has DTR "hotwired high", meaning that the
DTR wire is jumpered to some other signal that is always high (on).
If this is not what you desire, you should replace your cable with a
standard modem cable.
3. You are using a Macintosh with a "hardware handshaking cable". This
is actually the same situation as (2), except there is no way to
"fix" the cable - please read the ckmker.bwr file for an
explanation.
To work around these problems in Kermit, without actually fixing the underlying
cause, you can use a macro that escapes back to the modem's command processor
and gives it the command to hang up. Such a macro is predefined for you in the
MS-DOS Kermit 3.14 initialization file, MSKERMIT.INI:
; ATHANGUP macro. Use this if regular HANGUP command doesn't do the trick.
def ATHANGUP sleep 1,out +++,sleep 1,out ath0\13
(Note: C-Kermit uses this technique anyway.)
In MS-DOS Kermit, you can assign execution of this macro to the "hot key" of
your choice, for example:
set key \315 {\Kathangup} ; Assign ATHANGUP macro to the F1 key
In Mac Kermit, you can just go to the terminal screen and do it by hand:
- Pause at least one second
- Type +++
- Pause at least one second
- Type ATH0 (letters A, T, H, digit zero)
- Press the return key.
The modem should hang up and say NO CARRIER.
-------------------------------------------------------------------------------
14 HOW CAN I MAKE THE DIAL/REDIAL COMMANDS KEEP TRYING?
In Kermit 95, just click on the appropriate boxes in the graphical Dialer
(Options -> Dialing -> Procedures), or use the following commands at the
command prompt:
K-95> set dial retries 30 (How many times to redial)
K-95> set dial interval 20 (How long to wait between tries)
K-95> dial 5551212
In C-Kermit 6.0, use the "set dial retries" and "set dial interval" commands
shown above.
In MS-DOS Kermit, the DIAL command is defined in the MSKERMIT.INI file, and it
does indeed retry the call several times. REDIAL is also a macro, which simply
invokes the DIAL macro with the number most recently dialed; hence it, too,
tries the number several times. If you want to change the number of times that
the DIAL macro tries, or the conditions under which it retries, or the interval
between tries, simply edit the DIAL macro definition in MSKERMIT.INI.
-------------------------------------------------------------------------------
15 I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED.
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Sliding windows - only one is used?
Date: Wed Feb 15 09:21:08 1995
From: fdc@columbia.edu (Frank da Cruz)
In article <3hn07m$4dl@israel-info.datasrv.co.il>,
4th Dimension <winter@zeus.datasrv.co.il> wrote:
> I'm using MS-Kermit 3.14, PL3 on my PC, talking to C-Kermit 5A(190)
> on the remote Sun. When I start MSK, I load the FAST macro to get
> maximum thruput. Transfer of data is pretty fast, except that I
> never see more than one window used out of the three. Is this a
> bug, a feature, or am I doing something wrong?
>
It's not a bug and you are probably not doing anything wrong.
When two Kermit programs have agreed to use a maximum window size greater than
one, let's say 4, here is what happens:
The FILE SENDER can send up to 4 packets without waiting for an acknowledgement
from the file receiver. Each unacknowledged packet sits in the file sender's
window until it is acknowledged. Thus its window size grows from 1 to 2 to 3
to 4. If acknowledgments arrive quickly, the window might not grow to its
maximum size because it does not need to.
The job of the FILE RECEIVER is to accept and verify packets, decode them, and
write the decoded contents out to the file. If packets arrive in sequence,
then each one is processed and disposed of as soon as it arrives. If, however,
a packet arrives that has a sequence number that is more than one greater than
the previous packet that was successfully processed, this means that a packet
is missing. Thus the packet that just arrived can't be written out to disk
because if it were, the file would have a piece missing. So the
out-of-sequence packet is stored in the receiver's window until the missing
piece is filled in.
Thus you won't see the file receiver's window size exceed one unless there have
been transmission errors, no matter what window size the file sender might be
using. For greater detail see pages 102-103 of "Using MS-DOS Kermit" or pages
158-161 of "Using C-Kermit" (1st edition) or pages 256-260 of the second
edition.
- Frank
-------------------------------------------------------------------------------
16 HOW DO I WRITE A SCRIPT TO DIAL A PAGER?
A numeric pager is one that can display a number -- usually the number to be
called back. The number is entered by pressing Touch-Tone keys on your
telephone, usually terminated by pressing the "#" or "*" key.
Numeric pagers are not modems. Therefore when you dial one, it does not return
a carrier signal. Therefore, the dialing modem will not say "CONNECT" or turn
on its carrier signal. Therefore, DIAL commands will not succeed.
You can type commands to your modem manually for testing. For example:
ATDT7654321,,,,,8765432#;
In this example we Tone-dial the phone number "7654321", then we pause for ten
seconds (",,,,,") to give the pager time to answer the call, then we send
"8765432" to be displayed on the pager, then we send the "#" tone, and then we
return to command mode (";"). The modem should respond "OK". The details will
vary with your modem, your telephone service, and the pager you are dialing.
Let's assume we have a Hayes 2400 or higher compatible modem. Here's a sample
command file to call a numeric pager:
define \%a 7654321 ; Number to call
define \%b 8765432 ; Number to display on pager
set port xxxxxxx ; Select the communication device
set speed 2400 ; Any speed supported by the modem
output AT\13 ; Make sure it's in command mode
input 3 OK ; ...
if fail stop 1 Can't get your modem's attention
output {ATDT\%a,,,,,\%b#;\13} ; Make the call
input 3 OK ; ...
if fail stop 1 Can't place call
You can turn this into a macro that accepts the numbers as arguments. See
"Using MS-DOS Kermit" or "Using C-Kermit" for additional script programming
instructions, and your modem manual and the pager manual for details of calling
and paging. Note: the OUTPUT string is enclosed in curly braces to force the
commas to be taken literally (if you were using this command in a macro
definition and did not enclose the OUTPUT string in braces, the commas would be
command separators). Note #2 - Some modems might also support a "wait for
quiet answer" feature, e.g. by using the at-sign "@" in the dialing string:
ATDT7654321@8765432#;
What about alphanumeric pagers? You have to dial the paging service and then
either go through a series of prompts, or else execute a protocol like TAP.
C-Kermit 6.0 comes with a TAP paging procedure, ckepage.ksc.
You can also send an alpha page "by hand". The manual method goes like this
(at least for paging services that use TAP "manual mode"):
1. Set up the call.
2. Make sure that DIAL succeeds (Alpha pagers, unlike numeric pagers,
will send carrier back).
3. Look for "ID=".
4. Send uppercase "M" followed by carriage return.
5. You are prompted for the destination pager ID. Send it, followed by
a carriage return.
6. You are prompted for the text of the message. Send the text. It
might be restricted to one line, and even if not, it might be
restricted to a certain total length.
7. You might be prompted in some way for more pages or lines; you can
answer yes or no.
8. Assuming you answer no, optionally look for the farewell message,
then hang up.
The exact procedure and prompts vary according to the paging service, so you'll
need to go through the process manually to see exactly what the prompts and
sequences are. Then you can write a Kermit script to send manual-mode
alphanumeric pages automatically.
-------------------------------------------------------------------------------
17 WHEN C-KERMIT DIALS MY V.32BIS (OR V.34) MODEM, I GET THE ERROR 'CAN'T
CHANGE SPEED TO 14400 (OR 28800)'
Dialing is covered in detail in Using C-Kermit, second edition, and the problem
listed in the title of this section should occur only rarely in C-Kermit 6.0
(it was quite common in earlier versions).
To recapitulate very briefly: older modems, like the Hayes 1200 and 2400, that
did not do error correction or compression, but that could negotiate their
modulation speed, would report the modulation speed upon successful connection,
and change their interface speed to match. Thus, the communication software
would also have to change its own interface speed, or else the user would see
only garbage.
Modern modems have two different speeds: the interface speed and the modulation
speed. The interface speed can be kept constant even though the modulation
speed changes. Or not, depending on how the modem is configured.
C-Kermit versions prior to 6.0 had no way of knowing whether your modem is set
up to lock its interface speed, or to change it to match the modulation speed,
and therefore no way of knowing whether to believe the "CONNECT 28800" (or
whatever) message. By default, for compatibility with the huge installed base
of older modems, it did believe, and therefore changed its interface speed
according to the CONNECT message.
But if your modem's interface speed is locked (which it SHOULD be if it is an
error-correcting, data-compressing modem), you must tell Kermit NOT to change
its interface speed by giving it the command:
SET DIAL SPEED-MATCHING OFF
Now to complicate matters, some of the newer modulations report speeds that are
not commonly supported by the host operating system, such as 14400 and 28800.
Hence the message "Can't change speed to 14400" (or 28800). But even if these
speeds were supported, you would not want Kermit changing to them if the
modem's interface speed was locked. You would still see only garbage, but you
would not get the "Can't change speed" message.
C-Kermit 6.0, by contrast, has a much more comprehensive modem database, and
automatically chooses the appropriate SPEED-MATCHING and other parameters when
you choose your modem type. Therefore, when you choose a high-speed modem
type, one that is capable of speed buffering, C-Kermit automatically set DIAL
SPEED-MATCHING to OFF; whereas if you choose (say) the Hayes 2400 modem type,
it will set it ON. You can override these automatic choices by giving explicit
SET MODEM and/or SET DIAL commands after your SET MODEM TYPE command.
See "Using C-Kermit" for additional detail.
-------------------------------------------------------------------------------
18 HOW DO I USE KERMIT WITH PINE?
Here's a tip sheet we use at Columbia University - thanks to Joe Brennan.
SCREEN FORMATTING
Make sure that your UNIX terminal type agrees with Kermit's terminal emulation.
For example, if Kermit is emulating a VT320, tell UNIX:
export TERM=vt320
or:
setenv TERM vt320
If there is a complaint about "terminal type unknown" when starting Pine, then
try a lesser VT terminal model, such as VT220, VT102, VT100.
PRINTING
Pine's print command, letter Y, is known to work with MS-DOS Kermit and Mac
Kermit. With MS-DOS Kermit, if the printer is directly attached, it should
make the printer print the selected email message. With Mac Kermit, it should
send the selected email message into the printer buffer, which can be seen in
the Printer window, and which can be printed using the print command in the
pulldown File menu.
The command ''pcprint'' on UNIX (*), which prints any text file, does the same
thing as Pine's Print command. It may be easier to debug problems by running a
command like ''pcprint .profile'' at the UNIX shell ($ prompt).
(*) pcprint is a UNIX shell script:
---(cut here)---
echo -n '<ESC>[5i'
if [ $# -eq 0 ]; then
cat
else
cat $*
fi
echo -n '<ESC>[4i'
---(cut here)---
(Replace <ESC> by a real Escape (ASCII 27) character.
DOWNLOADING FROM PINE TO THE PC
Use Pine's command letter E, Export, to copy a message into a file. This file
will be created in your home directory on UNIX. Then it can be downloaded to
your PC or Mac using Kermit. After you finish, remember to remove the
now-unneeded file on UNIX, using the ''rm'' command at the $ prompt.
If you View a MIME-encoded message, Pine will ask whether to save it to a file
with a name of your choice. Pine will decode the message and create the file
in your home directory on UNIX. It can then be downloaded to your PC using
kermit. MIME-encoded files are often binaries rather than plain text, so you
should set kermit to transfer a binary file.
UPLOADING FROM THE PC TO PINE
Send email in plain text if possible. Save the document as plain ASCII text
with the PC application that created it. Use Kermit to upload it to UNIX. Run
Pine, choose letter C, Compose, and address your message as usual. Move the
cursor to the Message Text area and choose control-R, Read File, and type the
name the file (the copy on UNIX) to insert. You will see the file on screen,
as if you had typed it. If it looks strange, it's not plain text, so start
over. After you finish, remember to remove the now-unneeded file on UNIX,
using the ''rm'' command at the $ prompt.
If you want to send a PC document, use Kermit to upload it, setting Kermit to
transfer a binary file. Run Pine, choose letter C, Compose, and at the
Attchmnt: header, type the name of the file (the copy on UNIX). Pine will
encode it using MIME, and attach it to the end of any text you choose to type
in the message. *Note*: with MIME or any form of encoding, you should
determine whether the recipient of your message will be able to decode it.
Plain text email (previous paragraph) can be read on any email system.
-------------------------------------------------------------------------------
19 HOW DO I GET A SESSION LOG WITHOUT ALL THE EMBEDDED ESCAPE SEQUENCES?
This can be done in Kermit versions that have true terminal emulators, such as
MS-DOS Kermit and Kermit 95.
In MS-DOS Kermit:
- Don't LOG SESSION. Instead, SET PRINTER <filename>.
- Use Ctrl-Print Screen to "toggle" logging.
In Kermit 95:
- Don't LOG SESSION. Instead, SET PRINTER <filename>.
- Assign the Kverb \KprtAuto to the key of your choice, e.g. "set key
\315 \KprtAuto" to assign it to F1.
- Use this key to toggle logging.
The resulting file will contain only screen lines, and not the escape sequences
that put them there. The mechanism used internally is called "autoprint", and
works by sending each screen line to the printer or printer file when the
cursor leaves it.
In UNIX and OS-9 C-Kermit, you can "set session log text". This does not
filter out escape sequences, but at least it takes care of CR/LF/CRLF
conversion for you; see the description of this command in "Using C-Kermit".
-------------------------------------------------------------------------------
20 KERMIT DOESN'T WORK RIGHT WITH MY (RPI) ERROR-CORRECTING MODEM!
When you buy a modern error-correcting, data-compressing, speed-buffering
modem, you probably expect the modem to perform those functions, and most do.
Unfortunately, some modems that claim to have these features do not have them
at all, but require external software that implements them in your computer,
rather than in the modem where they belong.
The most widespread example of this practice is the Rockwell Protocol Interface
(RPI), a proprietary "standard" from Rockwell International Company that allows
modem companies to sell modems at a lower price by incorporating Rockwell chips
that do not include error-correction or compression capabilities.
This "standard" must be licensed from Rockwell, hence you will only find it
implemented in commercial software, such as on the diskette (if any) that came
with your modem.
In general, such software is available only for PCs running Microsoft Windows
3.x or Windows 95, or built into proprietary communications packages like
Comit.
If your modem documentation says it requires "RPI-compatible" software for
error correction and compression, and you want to use it with Kermit, then you
are out of luck unless you also have the software driver for the modem and can
use it on your computer. Otherwise you bought the wrong modem. Hopefully, you
can return it.
It is usually hard to tell by reading the modem box. One user reports: "The
RPI bit is hidden on the back of the box: '*Error Control* V.42 and MNP RPI
software,' and '*Data Compression* V.42bis RPI software.' The box design is
such that, unless you happen to already know what RPI is, you think you're
getting a modem with MNP/V.42 LAPM/V.42bis compression built in."
If you can't return the modem, you can still use it without error correction,
but then:
- Noise is not filtered out on the modem-to-modem connection, as it
would be with a real error-correcting modem, and noise bursts will
interfere with your online sessions and your file transfers.
- There is no modem-to-modem compression, because that requires error
correction.
- There is no flow control, because that too requires an
error-correction protocol between the modems.
- Speed buffering is ineffective because that requires flow control
between the modems. Thus, if the two modems have different interface
speeds, vast amounts of data will be lost.
Thus, none of the modem's "advanced features" are really there.
Why RPI is a bad idea:
- Implementation of MNP, V.42, and V.42bis in software is a VERY big
job. Since it is uneconomical for software companies to write
software for any platform other than Microsoft Windows, it is
unlikely that RPI drivers will ever be written for DOS, UNIX, OS/2,
VMS, or any other platform.
- Even when a company wants to produce a driver for (say) a new release
of Windows, there is generally a long lag time before it is
available. Thus you might find when you install your brand-new
operating system that your modem has become useless. (NOTE: Windows
95 will change its driver specifications soon, probably in mid-1997,
at which time all existing "WinRPI" drivers -- as well as drivers for
the other types of controllerless modems -- will stop working.)
- The driver software slows down your computer by consuming a vast
amount of CPU cycles over and above what would be used if
error-correction and compression were done in the modem, and it
increases memory requirements, swapping, and in general can be
expected to drag down the performance of your PC.
- RPI seeks to replace an open communication method (the one that is
universally used by serial communication software) by a closed,
proprietary, licensed one, and potentially hold hostage all
communications software developers to nondisclosure agreements.
- It precludes publication of source code.
- Since MNP 2-5 and V.42 and V.42bis are complex protocols, the
software implementations will inevitably be buggy and are unlikely to
be consistent, especially since the "standard" is not an open one,
and the implementations themselves will not be open.
- Even if the drivers are not buggy, the underlying operating system is
likely to be.
- Since not all software in the world will be "upgraded" to "support"
the RPI "standard", your modem will not be usable in many of the ways
you might have expected to use it.
- Many people will buy these modems under the mistaken impression that
they can use their high speeds and advanced features with their
favorite software. The average mass-market consumer is unlikely to
understand the implications of "requires RPI-compliant software" in
tiny print on the box.
- By Gresham's Law, "The bad drives out the good". RPI modems are
cheaper, and might well drive reputable modems out of the
marketplace, leaving the entire world's online community with no
modems left to choose from but ones that will work only with Windows.
This drives another nail into the coffin of "legacy" non-Windows
platforms, and this, in turn, leaves the public with fewer choices
for operating systems, applications, and computers themselves.
What are the benefits of RPI?
- Lower-cost modems? In order to save a few dollars, you are giving up
the ability to use the modem on the platform of your choice, with the
software of your choice, and you are probably going to get poorer
performance than you would have had with the EC and DC protocols
built-in over the life of the modem.
How do I tell if I have an RPI modem?
- According to Rockwell, all RPI modems should issue a message
containing "RPI" in response to the command ATI3. Here are some
examples:
AFEP-V1.510-BP39 ROCKWELL RPI (TM) MODEM
AFEP-V1.620z1.00 BS39 ROCKWELL RPI (TM) MODEM
V1.620-BP39 ROCKWELL RPI (TM) MODEM
- The command to enable error correction (such as AT&Q5, depends on the
modem) results in an ERROR response.
- They normally have AT+Hdigit commands to control the RPI interface.
(This one is not dependable, since there are no standards for modem
commands, and so AT+H might be used on non-RPI modems for some
entirely unrelated purpose.)
Is there a list of RPI modems?
- No. Just about any modem manufacturer is likely to have RPI models.
The modem market is incredibly volatile, fast-moving, and voracious.
Any such list would be obsolete before you could see it.
Once-scrupulous companies will now do anything to cut costs and
increase margins. They have no choice -- if your competitors are
doing it, you have to do it too or lose your business. Rockwell
licenses RPI "technology" to anyone who will pay for it, but is under
no obligation to disclose its licensees, nor are the licensees under
any obligation to inform Rockwell (or anybody else) which models
contain RPI chips and which do not. In many cases, the same make and
model can have RPI and non-RPI variations. This makes technical
support an increasingly difficult job. By saving a small amount of
money for themselves, the modem manufacturers have created unneeded
confusion among users and service providers, and driven up costs
throughout the online world.
Is RPI the only "software driven" modem scheme?
- No. There are similar products from other companies. This further
complicates the task of the help desks of the world, for even once
they have ruled out that a modem problem is due to RPI, it might be
some other kind of "controllerless" modem based, for example, on the
HSM chipset from AT&T (now Lucent). US Robotics now sells a
"Winmodem" (see next question). We can only expect to see more and
more of this in the future. As a maker of such items commented in
the comp.dcom.modems newsgroup, "There's certainly a market for
platform-independent modems, but you can't expect manufacturers to
ignore the market opportunity for Windows-only modems, especially
when they can have a cost and performance advantage."
Of course you can't. But what about end users who don't understand any of
this? Most of them do not make informed choices when buying modems. And
increasingly, many of them make no choice at all -- the modem comes
preinstalled in a PC they have bought, and does not even include a manual;
sometimes not even a brand name. And now that RPI modems have been out for a
while, we are beginning to see how they are passed from hand to hand, installed
in or connected to new computers (for use, e.g., with DOS or Linux) and causing
a whole new wave of problems.
If you have an RPI or other controllerless modem, and you need to use it in a
setting for which a driver is not available -- that is, in most cases, any
platform other than a PC running Microsoft Windows -- you are just plain out of
luck. Return it and buy a real modem. This way, you will encourage modem
manufacturers to continue to make real "platform-independent" modems.
To re-emphasize one of the worst aspects of these modems, here is independent
commentary from the comp.dcom.modems newsgroup, 14 Nov 96:
"If you don't plan to run [Windows 95], or more precisely, if you don't want to
run just versions of Windows '95 released between the initial launch and next
summer, then this modem may not be usable at all.
"Microsoft plans to change the driver interface in the near future and you will
need to get new drivers from somebody. This isn't a secret or anything; it's
part of the gradual merging of '95 and NT and they want a common driver for
both starting real soon. When this happens and you want to upgrade your OS,
you have to hope that your vendor will continue to support the model of modem
you bought and release new drivers. Those of you who get one of these modems
in a PC will have to fight with the PC maker and the modem maker when you try
to change (or upgrade) the OS on your PC.
"If your vendor makes new drivers available for the operating systems you want
to use for older models of their modems, you have no problem. If they won't
support last years modems at all, then you have a problem.
"Yet another reason to not buy modems with detached brains.
"It's like the Monty Python "New Brain" sketch. You really should pay the
extra $30 for a whole real brain in your modem. :-)"
(End quote)
-------------------------------------------------------------------------------
21 WHAT ABOUT WINMODEMS?
Refer to the previous section. Note, however, that Winmodems are even more
Windows-dependent than RPI modems, as they rely on the Windows drivers not only
for error correction and data compression, but for all of their modem
functions. Thus they are totally useless outside of Windows 3.1 or Windows 95,
and even under those operating systems, they can be used only by native Windows
applications, and not by DOS applications -- not even when they are running in
a Windows window. To quote from a posting to comp.dcom.modems from August 7,
1996:
"While the Winmodem does have some advantages over modems, this device and
others like it are generally inferior to a real and true modem. The Winmodem
isn't really a modem, it's just a DSP and a few other componants on a card. It
doesn't become a modem until you load up the Windows drivers for it. First off
this means that you're totally and completely stuck with Windows software. No
support for DOS in any way (not even through a DOS session in Windows), OS/2,
Linux, or even WinNT. Furthermore it uses your computer CPU for some tasks
normally handled by a processor in the modem. This drains some CPU power and
memory from your computer, which can slow applications down (although just how
much it'll slow things down depends on a number of factors)."
Thus you can not use MS-DOS Kermit with a Winmodem. You can, however, use
Kermit 95 in Windows 95 (not Windows NT) with a Winmodem; in this case you can
treat it as a Sportster.
-------------------------------------------------------------------------------
22 WHAT KIND OF MODEM SHOULD I BUY?
Refer to the previous two sections.
We have always recommended external modems. In the past, the principle reasons
for this were that:
- They can be connected to any kind of computer that has a serial port.
- You can monitor the lights for troubleshooting.
- They don't cause interrupt conflicts or address confusion, as
internal modems almost always do.
In recent times, the reasons to stick with external modems are all the more
compelling:
- Almost any recent-model modem is bound to have bugs and defects.
Therefore it is better to keep them outside of your PC, where they
can't affect the internal bus, configuration, or interrupt structure
of your computer.
- External modems are almost never "controllerless". To the best of
our knowledge, all RPI modems, Winmodems, etc, are internal PC
modems.
- External modems are never "Plug and Play". Plug and Play modems, to
the best of our knowledge, work only in Windows 95, and need special
OS-specific loaders to be initialized correctly. They can't be used
with DOS applications, even in a Windows 95 DOS window.
We do not recommend or endorse any particular brand of modem. However, we do
recommend the following attributes:
- It should be external rather than internal. The extra price is worth
it.
- It should follow established ITU-T (formerly CCITT) standards like
V.32bis, V.34, V.42, and V.42bis. If it claims to "exceed" standards
or "set" standards, beware; it is unlikely to interoperate correctly,
or at all, with modems from other manufacturers.
- It must not depend on operating-system-specific drivers or loaders
for any of its modulation, error-correction, or compression
functions. The operating system should be able to make full use of
it through its serial-port driver, with the application providing the
interface to the modem's command language. Thus you should be able
to change or upgrade operating systems without losing the ability to
use your modem.
Read the box carefully before buying.
-------------------------------------------------------------------------------
23 MY ARROW KEYS DON'T WORK
Newsgroups: comp.protocols.kermit.misc
Date: Mon Apr 24 10:24:29 1995
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: arrow keys and www?
Organization: Columbia University
In article <3n2s56$rb4@news-2.csn.net>,
Gideon Weisz <gweisz@csn.net> wrote:
>
> This has to be a very simple problem, so apologies in advance, but I
> am stuck. In www, using lynx, with mskermit 3.14 and vt220 (and
> HEBREW macro) the arrow keys do not work right. To move among
> highlighted links, one is supposed to use the up/down arrows and to
> move among levels the left/right keys. However, if I use
> right-arrow, I get "do you wish to send a comment"; if I use
> left-arrow it is taken as a command to download down-arrow moves me
> up! (up the screen to the last highlight).
>
Kermit is emulating a real VT220 terminal.
The VT220 cursor (arrow) keypad can be in one of two modes: cursor mode and
application mode. These keys send different escape sequences depending on
which mode they are in. When a VT220 is turned on (and when Kermit is
started), the arrow keys are in cursor mode.
By default (that is, unless you give SET KEY commands to change things), MS-DOS
Kermit uses the IBM keyboard arrow keys as the VT220 arrow keys. Each key has
a "verb" assigned to it:
Up arrow \Kuparr
Down arrow \Kdnarr
Right arrow \Krtarr
Left arrow \Klfarr
These verbs track the cursor keypad mode automatically, and send the following
escape sequences:
Cursor Mode Application Mode
\Kuparr CSI A SS3 A
\Kdnarr CSI B SS3 B
\Krtarr CSI C SS3 C
\Klfarr CSI D SS3 D
where CSI is ESC followed by left bracket ([) on a 7-bit connection or decimal
155 on an 8-bit connection, and SS3 is ESC followed by O (uppercase letter O)
on a 7-bit connection and decimal 143 on an 8-bit connection.
How does the cursor keypad mode change? The host can change it by sending
special escape sequences, or you can change it yourself by using the command:
SET TERMINAL ARROW-KEYS { CURSOR, APPLICATION }
So why do the arrow keys not work in Lynx? Or, in general, in any particular
application:
1. Because the application expects the keypad to be in one mode when it
is in the other mode. This is a deficiency on the part of the
application. Applications should never ASSUME which mode the cursor
keypad is in, but rather, they should PUT the keypad in the desired
mode, or else they should accept arrow-key codes from either mode.
Workaround: tell Kermit to SET TERM ARROW CURSOR (or APPLICATION).
2. Because of a terminal-type mismatch. Lynx, in particular, does not
seem to use the termcap database (it uses only terminfo), and so
therefore might not understand Kermit's VT220 or VT320 terminal type
(this kind of confusion typically occurs when a terminal type is in
the termcap database but not the terminfo one, and therefore works
with EMACS or vi, but not with Lynx). Solution: tell Kermit to SET
TERM TYPE VT100 and also tell the host your terminal type is VT100,
before starting Lynx, and ask you system administrator to add
missing terminfo entries.
3. Because of a character-size mismatch. If you have been using a
VMS-based VT220 or VT320 fullscreen application (such as ALEPH, EVE,
etc), you might find that your arrow keys are sending 8-bit codes
rather than 7-bit codes, and then when switching to another
application like Lynx, the new application might not understand the
8-bit codes. Again, this is a deficiency of the application.
Workaround: tell Kermit to SET TERM CONTROLS 7.
I put MS-DOS Kermit into Hebrew mode, accessed the ALEPH software, tried the
arrow keys and they worked OK. Then I left ALEPH and started Lynx and got the
same symptoms you reported. The three steps above fixed the problem.
- Frank
-------------------------------------------------------------------------------
24 KERMIT UNDER WINDOWS CAN'T FIND MY PORT
Q: We use Kermit 3.14 very heavily on our campus. From DOS everything works
great. From MS-Windows, however, sometimes it works but often our users will
get a message like:
unknown hardware for port, using BIOS...
or:
cannot use RTS/CTS on non-UART port
A: First, let's assume that your COM port is not, in fact, an internal
"controllerless" modem, such as a Winmodem or RPI modem -- you can't use these
with MS-DOS Kermit or, for that matter, with any non-Windows application or in
any operating system other than Microsoft Windows. See the section on RPI
modems for more information about this.
Windows and/or Windows communications programs tamper with the PC BIOS, where
Kermit goes to find out what ports are available and what their addresses (and
IRQs) are. The solution to this problem is to supply this information to
Kermit yourself.
Here is a macro you can use to set your port under Windows. MS-DOS Kermit 3.14
is required.
define PORT -
if not = \v(argc) 2 end 1 Port number required, -
if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, -
end 1 \%1 - bad port number, -
:PORT1, set com1 \x03f8 4, set port 1, end \v(status), -
:PORT2, set com2 \x02f8 3, set port 2, end \v(status), -
:PORT3, set com3 \x03e8 4, set port 3, end \v(status), -
:PORT4, set com4 \x02e8 3, set port 4, end \v(status)
Put this macro definition in your MSCUSTOM.INI file and then just tell Kermit
"port 1", "port 2", "port 3", or "port 4" instead of "set port 1", etc, and
everything should work as expected.
IMPORTANT: The addresses and IRQs are the most common ones, but they are not
going to work on every machine. PS/2s have different addresses and IRQs for
COM3 and COM4. Many add-on cards -- especially internal modems -- might use
different IRQs altogether, like 5. Again, see KERMIT.BWR for the gruesome
details.
Another user found that the following PORT macro also worked satisfactorily:
define PORT -
if not = \v(argc) 2 end 1 Port number required, -
if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, -
end 1 \%1 - bad port number, -
:PORT1, run {MODE COM1:19,N,8,1}, set port 1, end \v(status), -
:PORT2, run {MODE COM2:19,N,8,1}, set port 2, end \v(status), -
:PORT3, run {MODE COM3:19,N,8,1}, set port 3, end \v(status), -
:PORT4, run {MODE COM4:19,N,8,1}, set port 4, end \v(status)
-------------------------------------------------------------------------------
25 IF I HAVE AN ERROR CORRECTING MODEM WHY DO I NEED KERMIT PROTOCOL?
"If modern modems are capable of hardware error correction and compression,
isn't it redundant and inefficient to continue to use file-transfer protocols
like Kermit and ZMODEM that provide the same services?"
This is a common misconception, and, unfortunately, one that is promoted by
many of the modem makers themselves (e.g. when you read about protocols in the
modem manuals). The modem makers (some of them) might excel at what they do,
but they are generally not experts on computers and software. For example, the
following appears in a current modem manual:
Generally, the most efficient file-transfer operations are achieved
when the EC modem does the error checking in hardware, and the
file-transfer protocol does not duplicate this effort. The YMODEM-G
file-transfer protocol provides this level of service. This protocol
was written for use with high-speed, error-control modems. This
protocol does not provide any error-detection or recovery capability.
But it is not true that protocols like YMODEM-g (or, as is often suggested by
newcomers to modem communication, no protocol at all) are the best to use with
error-correcting modems.
That's because errors can also occur (and often do) outside the modem-to-modem
connection. The most common causes are lack of sufficiently effective DCE/DTE
flow control and resulting buffer overflows in the receiver; unbuffered UARTs
that can't be serviced fast enough by a busy or slow CPU; interrupt conflicts
(including characters lost due to having interrupts turned off by other
drivers, e.g. disk-caching programs), and on and on -- things that are beyond
the modem's control.
Second, you don't always know that your error-correcting modem will make a
successful MNP or V.42 connection with the other modem. The two modems might
have mismatched capabilities or there might be a "failure to negotiate" the
capabilities they do have. Would you want to use different file transfer
methods depending on the type of connection negotiated by the modems? Not a
good use of your time.
Third, the communication channel outside the modems might not be fully
transparent. For example, it might chop off the 8th bit of each byte, or it
might filter out certain characters, or use them for special purposes rather
than treating them as data. This is common with terminal servers and other
types of communications front ends.
Fast protocols like Zmodem and modern Kermit impose little additional overhead,
and that small amount of overhead is well worth the savings in failed
transfers, which are inevitable when using non-recovering methods in situations
like the ones described above.
But even more fundamentally: you can't know in advance that there will be no
errors. So using a file transfer procedure without error recovery is silly,
because if there are errors, you'll have to start all over again. It's like
not buying fire insurance for your house because you think it is fireproof.
Finally, what happens when the connection is broken? Say, after transferring
99 megabytes of a 100-megabyte file? Error-correcting modems can't stop wires
from being cut or pulled out, nor can they prevent power failures or keep
computers or applications from crashing. So again, you need a good error
recovery protocol. Both Zmodem and Kermit can pick an interrupted transfer up
from the point of failure.
-------------------------------------------------------------------------------
26 HOW DO I USE 'SET KEY' WITH PC F-KEYS, ETC, IN UNIX OR VMS C-KERMIT?
The C-Kermit versions for UNIX, VMS, and so on, that do not have direct access
to the keyboard and screen, and rely on your console driver, terminal window,
external terminal emulator (such as MS-DOS Kermit), or actual terminal to
perform the terminal functions.
UNIX is an interesting case. Traditionally, UNIX was accessed through a
terminal that was plugged into a terminal port on a timesharing system. Thus,
there is no keyboard and screen -- just a communication port. In recent years,
this type of access has been largely replaced by terminal servers, but there is
still no keyboard and screen. However, now that we have a plethora of PC-based
UNIX varieties that run on workstations (PCs) that actually do have a keyboard
and screen, it would seem to make sense that Kermit should be able to see all
the keys.
Unfortunately, this is not the case. Most varieties of UNIX do not let the
application see the keyboard. There is no kernel function called "get keyboard
scan code". There is only read(), and read() reads a character, not a
multibyte scan code. Thus, even if your console driver has programmed (say)
your F1 key to send (say) ESC O P, Kermit will read three characters in
succession, as if they were three keystrokes, not one. It has no way of
knowing that you pressed the F1 key. As far Kermit knows, you pressed the Esc
key, then the O key, then the P key.
Now perhaps Linux *does* have a system call to let an application at the
keyboard. But...
- In what contexts does it work? Only on the raw console? In an xterm
window? etc etc.
- Does it require special privilege to execute?
- What about all the other versions of UNIX that run on PCs -- FreeBSD,
SCO, Solaris/Intel, etc etc?
- What about all the other versions of UNIX that run on non-PC
workstations -- SunOS, Solaris/Sparc, HP-UX, AIX, SGI, etc?
So the answer is, for now at least -- and as the documentation states --
C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only for
keys that generate a single 8-bit value, 0..255. Other types of mappings will
have to be accomplished outside of Kermit by configuring your console driver,
your xterm (e.g. with Xmodmap), and so on.
-------------------------------------------------------------------------------
27 HOW CAN I EXIT FROM C-KERMIT WITHOUT HANGING UP?
Many people want to be able to make a dialout connection with UNIX C-Kermit,
but then use some other software on the connection that C-Kermit made. For
example, they want to use C-Kermit as their SLIP or PPP dialer. But they
quickly find that when they exit from C-Kermit, that the connection is gone
before they can start the other application.
It is a fundamental property of UNIX (and VMS, and Windows 95 and NT, and most
other modern operating systems) that when a process exits, then every file that
was opened by that process is automatically closed by the operating system. In
most cases, closing a terminal device (such as a dialout serial port) hangs up
the modem (by turning off the DTR signal). There is nothing the process can do
about it.
However, many workarounds are possible. Here are just a few:
- If your Kermit version supports the REDIRECT command, use it to start
the desired application (e.g. "redirect pppd"). Read about the
REDIRECT command in the second edition of Using C-Kermit.
- Tell C-Kermit to SET MODEM HANGUP-METHOD RS232, and then configure
your modem to ignore DTR (not recommended).
- Find out the file descriptor of the open device (it is given by
C-Kermit's \v(ttyfd) variable) and then run ("!") your other program
from the C-Kermit prompt, feeding it the file descriptor, e.g.
through shell redirection or a command line option (the method
depends on the other program, the capabilities of the shell, etc).
- After Kermit makes the connection, type "show comm" to find out the
filename of the lock file. Then suspend Kermit, delete the lock
file, then start the other program and tell it to open the same tty
device.
Note that you can also tell C-Kermit to use a communications file descriptor
created by another process; see the command-line options list in "Using
C-Kermit", 2nd edition.
-------------------------------------------------------------------------------
28 WHAT IS SUPERKERMIT?
When the Kermit protocol was first developed in 1981, it had short packets and
did not use sliding windows, but the design was deliberately extensible to
allow for the addition of these and many other features later.
A couple years later, when we defined the protocol for long packets and sliding
windows, somebody somewhere started calling it "SuperKermit". Really, there's
no such thing -- Kermit is Kermit. It's an extensible protocol in which the
two file transfer partners negotiate automatically about what features they
have in common and agree to use them.
All modern Columbia Kermits support long packets and sliding windows (except
IBM Mainframe Kermit does not "do windows" because it exists only in a
half-duplex environment, whereas full duplex connections are needed for sliding
windows). They also support compression, single and locking shifts (for moving
8-bit data efficiently through 7-bit communication channels), file-transfer
recovery, dynamic packet lengths and timeouts, and all sorts of other advanced
and serious features that whoever coined the term "SuperKermit" never dreamed
about.
Usually when BBSs or non-Columbia communication programs refer to "SuperKermit"
they mean a 1985-vintage implementation of the Kermit protocol that implements
a primitive and not very robust form of sliding windows, usually not in
combination with long packets. However, if it is properly implemented, it
should interoperate successfully with any other Kermit implementation, no
matter how advanced or how minimal. That's the whole point of Kermit protocol.
-------------------------------------------------------------------------------
29 IS KERMIT SOFTWARE YEAR-2000 COMPLIANT?
Kermit software is not, for the most part, date dependent. It makes
connections, performs terminal emulation (in those versions that include this
feature), transfers files, translates character sets, and, in most cases,
executes scripts regardless of the date.
"Year 2000 compliance" depends on the Kermit program and the underlying
platform. If the operating system, file system, BIOS, hardware, and/or other
critical component is not ready for the year 2000, then most likely Kermit
isn't either, since it relies on the underlying OS and hardware for date / time
service.
The primary relevance of this question to Kermit software is whether
post-millenium file dates are recognized, transmitted, received, and reproduced
correctly during the file transfer process. This consideration, in turn,
applies only to those Kermit versions that implement the optional "Attribute
Packet" feature. These include C-Kermit, Kermit 95, MS-DOS Kermit, Kermit-370,
and PDP-11 Kermit. If post-millenium dates are not processed correctly, file
transfer will still take place, but the creation or modification date of the
received file might be incorrect. The only exception would be if the "file
collision update" feature is being used to prevent unnecessary transfer of
files that have not changed since the last time a transfer took place; in this
case, a file might be transferred unnecessarily, or it might not be transferred
when it should have been. Correct operation of the update feature depends on
both Kermit programs having the correct date and time.
Of secondary importance are the time stamps in the transaction and/or debug
logs, and the date-related script programming constructs, such as \v(date),
\v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time)
and \v(ntime), insofar as they might be affected by the date. Note: the
aforementioned script programming constructs are available only in C-Kermit,
Kermit 95, and MS-DOS Kermit. The \v(ndate) is a numeric-format date of the
form yyyymmdd, suitable for comparison and sorting: e.g. 19970208 or 20011231.
If the underlying operating system returns the correct date information, these
variables will have the proper values. If not, then scripts that make
decisions based on these variables might not operate correctly.
Here is the current situation for the most popular Kermit software products.
The minimum version known to be Year-2000 compliant is shown. We make no
claims whatsoever about the underlying operating systems or file systems. The
situation with Kermit programs not listed here is at present unknown.
MS-DOS: MS-DOS Kermit: Version 3.15 or later required.
Windows 3.1: MS-DOS Kermit: Version 3.15 or later required.
Windows 95: Kermit 95: Version 1.1.3 or later required.
Windows NT: Kermit 95: Version 1.1.3 or later required.
OS/2: Kermit 95: Version 1.1.11 or later required.
UNIX: C-Kermit: Version 6.0.192 or later required.
VMS: C-Kermit: Yes, all versions. Kermit-32: unknown; Kermit-32 has
not been supported since about 1987.
Stratus VOS C-Kermit: Version 6.0.192 or later and VOS 12.3 or later
required.
VM/CMS: CMS Version 13 and Kermit-370 Version 4.3.2 or later required.
Note: 4.3.2 is not formally released yet, but the patch up to
this version is included as an optional "new update" file with
the current release, 4.3.1.
MVS/TSO: Kermit-370 for TSO: Version 4.3.2 or later required.
MVS/ROSCOE: Kermit-370 for ROSCOE: Version 4.3.2 or later required.
MUSIC: Kermit-370 for MUSIC: Version 4.3.0 or later required.
CICS: Kermit-370 for CICS: Version 4.3.0 or later required.
RT-11: KRT for RT-11 and TSX+: Version 3.63 or later required.
RSTS/E: KRT for RSTS/E: Version 3.63 or later required.
-------------------------------------------------------------------------------
30 IS THERE A KERMIT LIBRARY?
No, the Kermit Project does not supply an OLE or OLE-2 interface, a Kermit
library, DLL, VBX, OCX, Active X control, Delphi component, or other type of
Kermit module designed purely for embedding in other applications. We
recommend that those who wish to embed communications functions -- connection
establishment, logging in and other dialogs, file management, data transfer --
do so by invoking an existing Kermit program -- MS-DOS Kermit for DOS or
Windows 3.x, Kermit 95 for Windows 95 or NT or OS/2, C-Kermit for UNIX or VMS,
etc -- from within their application by a combination of command-line arguments
and command files (Kermit script programs). If you have trouble with this, ask
us for assistance. And of course, if you are providing this application to
customers or clients, you must license the Kermit software from the Kermit
Project.
-------------------------------------------------------------------------------
31 HOW DO I CALL UP A DIALBACK SERVICE?
A dialback service is one which you dial up to, provide some kind of
identification and/or authentication, such as a name and/or password, and then
it looks up your phone number in a database and calls you back. It is a type
of security, based on having the phone numbers of all authorized callers, and
opening sessions for them only when they are calling from those numbers.
Suppose you were using a Hayes modem to make a call to a dialback service. You
would do the following:
ATD7654321 (Dial the number)
CONNECT 14400 (Read the response)
Here you would have the identification / authentication dialog. Now the
dialback service hangs up on you, and you must put the modem in answer mode:
NO CARRIER (The connection is closed)
ATS0=1 (Tell the modem to answer the next call)
When the call comes in, the modem answers and you're on line.
But now you want to automate the process. This is easily accomplished in
Kermit. Let's use C-Kermit 6.0 to illustrate, since it has a new ANSWER
command. Here is a simple script to do the job:
set modem type usr ; or whatever
set port /dev/cua ; or whatever
set speed 38400 ; or whatever
dial 7654321 ; dial the number
if fail stop
At this point, you would use INPUT and OUTPUT commands to accomplish the
identification / authentication dialog. For example, if the dialback server
prompts you with USERNAME: and PASSWORD:, and your script had previously stored
these values in the variables \%u and \%p, respectively:
input 10 USERNAME:
if fail stop 1 No username prompt
output \%u\13
input 10 PASSWORD:
if fail stop 1 No password prompt
output \%p\13
Now you will need to hang up your end of the connection, and then wait for the
phone to ring:
hangup
answer 120
if fail stop 1 No callback
The ANSWER command conditions the modem for answering (ATS0=1 for Hayes and
compatible modems) and then waits the given number of seconds (120 in this
case) for the call to come in. At this point, if the script is still
executing, you've got a connection. You can give a CONNECT command, or execute
a login script, or whatever else you want to do.
-------------------------------------------------------------------------------
32 HOW DOES THE NUMERIC KEYPAD WORK?
This discussion applies to MS-DOS Kermit. The situation with Kermit 95
is slightly different: In Kermit 95, the Num Lock key can be mapped
directly and the PC numeric keypad is mapped to the VT terminal
numberic keypad by default.
MS-DOS Kermit reads scan codes from the PC BIOS (but if you are using Windows,
then all sorts of software layers are inserted between Kermit and BIOS, so
matters are somewhat more uncertain.
The BIOS reports one scan code for a numeric keypad key when Num Lock is on,
and a different code when Num Lock is off. All that MS-DOS Kermit is doing is
reading the scan codes from (what it thinks is) the BIOS.
To use the PC's numeric keypad as if it were a VT terminal's numeric keypad in
MS-DOS Kermit, you must make the appropriate key assignments, since they are
not made by default. By default, when Num Lock is not on, the keys have the
same assignments as the gray keys which have the same label (e.g. Home, End,
Left Arrow, etc), for the benefit of 88-key keyboards.
To make the desired key assignments, you can use the VT300.INI file in the
KEYBOARD subdirectory of the MS-DOS Kermit directory:
take keyboard\vt300.ini
The pertinent commands from this file are:
set key \850 \kkp0 ; Keypad 0 (Numlock) Keypad 0
set key \338 \kkp0 ; Keypad 0 (Normal) Keypad 0
set key \847 \kkp1 ; Keypad 1 (Numlock) Keypad 1
set key \335 \kkp1 ; Keypad 1 (Normal) Keypad 1
set key \848 \kkp2 ; Keypad 2 (Numlock) Keypad 2
set key \336 \kkp2 ; Keypad 2 (Normal) Keypad 2
set key \849 \kkp3 ; Keypad 3 (Numlock) Keypad 3
set key \337 \kkp3 ; Keypad 3 (Normal) Keypad 3
set key \843 \kkp4 ; Keypad 4 (Numlock) Keypad 4
set key \331 \kkp4 ; Keypad 4 (Normal) Keypad 4
set key \844 \kkp5 ; Keypad 5 (Numlock) Keypad 5
set key \332 \kkp5 ; Keypad 5 (Normal) Keypad 5
set key \845 \kkp6 ; Keypad 6 (Numlock) Keypad 6
set key \333 \kkp6 ; Keypad 6 (Normal) Keypad 6
set key \839 \kkp7 ; Keypad 7 (Numlock) Keypad 7
set key \327 \kkp7 ; Keypad 7 (Normal) Keypad 7
set key \840 \kkp8 ; Keypad 8 (Numlock) Keypad 8
set key \328 \kkp8 ; Keypad 8 (normal) Keypad 8
set key \841 \kkp9 ; Keypad 9 (Numlock) Keypad 9
set key \329 \kkp9 ; Keypad 9 (Normal) Keypad 9
set key \334 \kkpminus ; Keypad + Keypad -
set key \2382 \kkpcoma ; ALT Keypad + Keypad ,
set key \851 \kkpdot ; Keypad . (Numlock) Keypad .
set key \339 \kkpdot ; Keypad . (normal) Keypad .
set key \4365 \Kkpenter ; Keypad Enter Keypad Enter
; F1 PF1 (default Kermit)
; Use GOLD.COM to make Num Lock work as PF1/Gold.
set key \325 \kPF1 ; This works with WPGGOLD.COM.
set key \4399 \kPF2 ; Keypad / PF2
set key \311 \kPF3 ; Keypad * PF3
set key \330 \kPF4 ; Keypad - PF4 Key
You need the GOLD TSR to make the Num Lock key work like the DEC Gold key. The
GOLD TSR is found in the same directory as the VT300.INI file.
The rest of the commands in the VT300.INI file set up the function keys and
editing keys to be like the corresponding DEC VT220/320 keys.
But there is still one more piece to the puzzle. As noted, the VT keypad can
be in one of two modes: numeric or application. It is the responsibility of
the host application to send an escape sequence to put the keypad into the
appropriate mode before attempting to read keystrokes from it. But some
applications fail to do that and simply ASSUME that the keypad is in the right
mode. In many cases this assumption is wrong. So MS-DOS Kermit has a command
that lets you force the keypad into the desired mode:
SET TERMINAL KEYPAD { APPLICATION, NUMERIC }
-------------------------------------------------------------------------------
33 HOW TO GET RID OF THE "OK TO EXIT?" PROMPT?
When I try to exit from Kermit it says:
A serial connection might still be active on com2.
OK to exit?
But the connection is closed! How do I make this message and prompt go away?
It prevents scripts from running unattended.
Short answer:
SET EXIT WARNING OFF
Long answer: Kermit gives this message and prompt when given the EXIT command
(explict or implied), or when told to change its communication device, and a
connection appears to be active on the current one. On a serial device, this
means that the Carrier Detect (CD) signal is still present. On a network
connection, it means that Kermit has not closed the connection and it does not
seem that Kermit's network partner has closed it either.
If you are using a modem, the best course is to fix it (or the cable) so CD
tracks the connection. Kermit generally tries to do this itself, but sometimes
it is not possible due to switch settings in the modem. See your modem manual
for details.
In some cases, however, the underlying operating system or device driver does
not provide Kermit with good information.
If you can't fix the modem or cable to report the connection status properly,
use SET EXIT WARNING OFF to tell Kermit to ignore the apparent connection
status upon EXIT.
-------------------------------------------------------------------------------
34 HOW TO TELL KERMIT TO IGNORE DIALTONE?
Sometimes the telephone being used to place a modem call does not present a
dialtone that the modem recognizes. This usually happens with PBXs, ISDN
phones, etc. But Kermit programs generally tell the modem to wait for dialtone
before dialing.
To find out how to get around this feature, you'll need to look at your modem
manual. If it's a Hayes compatible (i.e. uses the AT command set), then it's
probably a matter of changing the "X" value in the init string. Most Kermit
init strings use X4, in order to get the widest possible selection of result
codes. In many modems, X3 is used to select "blind dialing" (i.e. without
waiting for dialtone), but this also sacrifices the ability to get a BUSY
response, and therefore to redial automatically if the line is busy. Hopefully
your modem has finer-grained selections.
In C-Kermit or Kermit 95, a good way to change the X value in the init string
is, after you set your modem type:
set modem type xxxx
set modem command init \freplace(\v(m_init),X4,X3)
This assumes your modem type is "xxxx", and its init string contains X4.
In MS-DOS Kermit, just edit the dialing script.
-------------------------------------------------------------------------------
35 WHERE IS THE DIALING SCRIPT FOR MY MODEM?
C-Kermit and Kermit 95 do not use dialing scripts; their modem support is built
in. To see a list of the modems supported, type:
set modem type ?
at the prompt. If your modem is not listed, then (a) maybe one of the other
modem types will work ("generic-high-speed" is usually a good guess), and (b)
you can install your own modem definition as described on pages 90-92 of Using
C-Kermit; this, of course, requires knowledge of how to operate your modem,
which comes from reading the manual (if any) that came with it.
MS-DOS Kermit, on the other hand, uses dialing scripts, one per modem type.
The ones we have are in the MODEMS subdirectory of your MS-DOS Kermit
directory. If you don't see one there for your modem, it is easy to adapt one
of the existing ones. Just use a text editor to change the modem-specific
commands to the ones for your modem; consult your modem manual to find out what
its commands are.
In either case, if you have added support for a new modem, please send your new
definitions or script back to us, along with a complete description of your
modem's manufacturer, name, model designation, and features (modulation, error
correction and compression protocols, etc), so we can make them available to
others.
-------------------------------------------------------------------------------
36 I'M HAVING TERMINAL EMULATION PROBLEMS WITH C-KERMIT
C-Kermit on UNIX, VMS, etc, does not perform terminal emulation at all; nobody
ever claimed it did. Instead, it is a semitransparent (or, if you make it so)
a fully transparent communications pipe between the remote computer or service
and your local terminal, terminal emulator, terminal window, or console, which
provides the terminal functions. Thus, it is similar to Telnet, cu, tip, "set
host" in VMS, etc, but with added functionality (file transfer and management,
character-set translation, scripting, etc).
If you experience fractured screens, you probably have a mismatch between the
type of terminal or emulator you are running C-Kermit and the type the remote
host or service thinks you have. Solution: let the host know what type of
terminal you really have. For example, in Linux it would be ANSI or SCOANSI.
In an HPTERM window, it would be HPTERM. In an AIX window, it would be
AIXTERM, etc.
If your arrow and function keys don't work, then you must configure your
terminal or emulator to have these keys send what the host or application
expects them to send. The method for doing this depends on your terminal or
emulator. For example, when using xterm or another X-based terminal window,
use xmodmap to configure your keyboard. C-Kermit itself can't be used for this
(even though it has a SET KEY command) because it can't "see" the special keys
(arrow keys, function keys, editing keys, etc).
If host-directed transparent printing doesn't work, this is a deficiency in
your terminal or emulator and has nothing to do with Kermit. However, if you
have the ability to change the host application, then you can use C-Kermit's
autodownload and/or APC features to accomplish the same thing. See the manual
for details.
-------------------------------------------------------------------------------
37 DIVIDE OVERFLOW IN MS-DOS KERMIT
If you find that MS-DOS Kermit is giving you "Divide Overflow" errors after an
OS or hardware upgrade, or on a new PC:
- If your PC is running Windows 95, Windows NT, or OS/2, then you
should run the 32-bit version of Kermit for those platforms Kermit
95. This is the only Kermit software that is recommended or
supported for Windows 95, Windows NT, or OS/2.
- If your PC is running DOS (MS-DOS, PC-DOS, DR-DOS, etc) as its base
operating system (and perhaps Windows 3.x on top of that), then
upgrade your version of MS-DOS Kermit to the current release, MS-DOS
Kermit 3.15
-------------------------------------------------------------------------------
(End)